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(54) Query interface for OLAP cubes 



(57) A database interface for generating drill- 
through paths for various data cubes, derived from dif- 
ferent report generating applications is disclosed. The 
interface comprises: (a) means for accepting a request 
from a user for data; (b) means for translating the re- 
quest into a drill-through path selected from a plurality 
of possible drill-through paths between a source and a 



target; (c) means for applying one or more parameters 
to the selected drill-through path to produce a valid drill- 
through path and to transfer the requested data over the 
valid drill-through path to an application; and (d) display 
means for displaying the requested data to the user. 
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Description 

Field of the Invention 

[0001] The present invention relates to interactively 
searching a database in such a manner that it is quick 
and easy to search, drill down, drill-up and drill across 
a data collection, presenting the user with summary in- 
formation using multiple independent hierarchical cate- 
gory taxonomies of the data collection. The present in- 
vention also relates to retrieving information from a da- 
tabase based on content aggregation, management 
and distribution. 

Background of the Invention 

[0002] The field of business applications of computer 
technology has seen many important changes over the 
last few years. With steadily growing computational 
power and data storage capacities of computer systems 
used for business data processing, the interest of the 
business community has shifted from transactional data 
management systems known as on-line transaction 
processing (OLTP) systems, mostly supporting day-to- 
day business operations, and from relatively simple 
business data processing systems, towards sophisticat- 
ed business management systems, such as online an- 
alytical processing (OLAP) and business intelligence 
(Bl) systems, integrating at the enterprise level many 
facets and functions of the business, including planning, 
manufacturing, sales and marketing. Collectively, these 
are often termed decision support systems. 
[0003] Among various alternative approaches to busi- 
ness data management and analysis developed over 
the last few years, many are related to data warehous- 
ing. A data warehouse can be defined broadly as a sub- 
ject-oriented collection of business data identified with 
a particular period of time, as opposed to a transactional 
database which is dedicated to ongoing business activ- 
ities. Data in a warehouse is normally gathered from a 
variety of sources (mostly various OLTP and legacy sys- 
tems) and merged into a coherent whole. Data in aware- 
house is usually stable, with data being added to the 
warehouse periodically but usually not removed. How- 
ever, in some cases the oldest data may be unloaded 
when the newer data is added. 

[0004] As opposed to data stored in OLTP systems 
intended to support day-to-day operations and opti- 
mized for the speed and reliability of transaction updat- 
ing, data stored in a data warehouse is intended to pro- 
vide higher-level, aggregated views of the data in sup- 
port of business decision making. This might include to- 
tal sales by product line or region over a selectable pe- 
riod of time. To provide consistently fast responses to 
such aggregating queries, data in a data warehouse 
must be structured in a manner facilitating its synthesis, 
analysis, and consolidation. 

[0005] The most characteristic feature of warehoused 



business data is its multidimensional view of a business 
- so-called because the business data is organized ac- 
cording to major aspects and measures of the business 
called dimensions. The dimensions for a business may 

5 include its products, markets, profits, or time periods in- 
volved. This is in contrast to a data dependencies model 
of the business data used to keep track of all logical re- 
lationships among all the possible data elements rele- 
vant to the business and its day-to-day operations. 

w [0006] A dimension may include several hierarchical 
levels of categories. For example, the market dimension 
may contain, in descending order, such categories as 
country, region, state, and city, each category having its 
own number of specific instances. A hierarchical dimen- 

15 sion reduces the total number of dimensions necessary 
to describe and organize the data, as compared with the 
situation where each category is represented by a sep- 
arate dimension. 

[0007] The action of viewing data in greater detail by 
20 moving down the hierarchy of categories, i.e., by moving 
from parent to child category, is sometimes referred to 
as "drilling down" through the data. Quite naturally, the 
action of moving in the opposite direction, i.e., up the 
hierarchy of categories, to produce a more consolidat- 
es ed, higher-level view of data, is known as "drilling up" 
through the data. Another aspect of this 'drilling' is the 
ability to 'drill through' from one form of data to another 
where the data are collected in reports having different 
meta-data models and/or data sources, but where the 
30 actual data are compatible (or able to be converted to a 
compatible form) for use in an application. Drill-through 
is sometimes defined as the action of navigating from 
one report to another report and applying the context of 
the source to the target. Drilling is further discussed be- 
35 low. 

[0008] The vast amounts of warehoused or otherwise 
collected business data would be useless without soft- 
ware tools for its analysis. Such tools are known under 
the collective name of business intelligence (Bl) appli- 
40 cations, an example of which is a suite of Bl applications 
from Cognos Inc. (Canada). Bl applications provide, 
among other features, data warehouse construction 
tools, as well as database querying, navigation and ex- 
ploration tools, and also include reporting, modeling, 
45 and visualization tools. Some of these tools combine 
techniques of data analysis and presentation with meth- 
ods for discovering hidden patterns and previously un- 
recognized relationships among data, an approach 
sometimes known as data mining. 
50 [0009] Among Bl applications previously made avail- 
able to the business community, tools for visualizing 
business data are of particular importance. By interact- 
ing with the user graphically or pictorially, these tools 
have become the means of choice for consolidating and 
55 presenting vast amounts of complex information, in a 
manner which facilitates pattern recognition in the pre- 
sented data and invites data exploration. 
[0010] For example when invoking a drill-through op- 
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eration from a row of the source report to a target report, 
a filter is constructed based on the source report row 
and the filter is then applied to the target report. This 
filter is then used by an application in requesting data 
from another application. 5 
[001 1] Using earlier technology it is necessary to ap- 
ply some very strict rules in order to effectively drill from 
one application to another. The drill-through filter gen- 
erated from the drill-through source is required to match 
up with the column names used in the target report. This 10 
column name matching is typically done through a set 
of intermediate files called query definitions (QD). A QD 
file is essentially the SQL query that can be used by a 
transformation program to generate a new data cube. 
The QD file contains the column name mapping used to 15 
generate the context filter that the target application can 
understand. In general, a context filter helps restrict the 
target report data based on the context (or some con- 
tent) from the source report. For example, a context filter 
might specify "color='red"' because that was the value 20 
contained in a cell selected in the source report. Then 
the target report will only show the sales data for appli- 
ances that are red. The process is duplicated for each 
source/target application pair, although in each case the 
intermediate files may have slightly different formats, 25 
but they still served as a column name map. 
[0012] For convenience, the following definitions are 
given for terms that are used throughout this application: 

Business Intelligence Tools: Software that enables 30 
business users to see and use large amounts of 
complex data. The following three types of tools are 
referred to as Business Intelligence Tools: Multidi- 
mensional Analysis Software - also known as On- 
line Analytical Processing (OLAP) - Software that 35 
gives the user the opportunity to look at the data 
from a variety of different dimensions. Query Tools 
- Software that allows the user to ask questions 
about patterns or details in the data. Data Mining 
Tools - Software that automatically (and sometimes 40 
interactively) searches for significant patterns or 
correlations in the data. 

Cube (also known as Multidimensional Cube): The 
fundamental structure for data in a multidimension- 
al (OLAP) system. A cube contains dimensions, hi- 45 
erarchies, levels, and measures. Each individual 
point in a cube is referred to as a cell. 
Data-Based Knowledge: Knowledge derived from 
data through the use of Business Intelligence Tools 
and the process of Data Warehousing that give us 50 
a new kind of knowledge based on data. Data- 
based knowledge can have several advantages 
compared to experience/intuition-based knowl- 
edge: Improved accuracy - because it is based on 
so many detailed facts. More current - because the 55 
data warehousing and business intelligence tools 
can so quickly analyze new data. More comprehen- 
sive - because so many different perspectives are 



available through the rapid recombination of ele- 
ments from different dimensions and different levels 
of the data hierarchy. New insights are possible - 
because there are complex patterns in the data that 
can be discovered by data mining that would never 
be detected by human analysis. Less subjective - 
because conclusions are tied directly to the physical 
data. 

Dimension: One of the perspectives that can be used 
to analyze the data in an OLAP cube. When browsing 
the data in a cube, it is possible to view the data from 
the perspective of different combinations of dimen- 
sions. For a Sales database, the dimensions might 
include Product_Name, Time_of_Sale, Store_Name, 
and Promotion_Name. Dimensions contain one or 
more hierarchies, which have levels for drilling up and 
drilling down in the cube. When a dimension has just 
one hierarchy, which is quite common, people often 
refer to the dimension itself as having levels. 
Hierarchy: Organization of data into a logical tree 
structure. Dimensions can have one or more hier- 
archies. A Time dimension, for example, might have 
a Calendar hierarchy and a Fiscal hierarchy. Hier- 
archies contain levels, which organize data in a log- 
ical structure. It is the combination of multidimen- 
sional data with a hierarchical view given by Busi- 
ness Intelligence Software that allows users to 
grapple successfully with large amounts of data. If 
each member in a level has 5 to 1 0 children that are 
members at the next lower level, the user has a bet- 
ter chance of understanding the significance of the 
data. Moving between the levels of a hierarchy is 
called drilling up and drilling down. 
Level: The hierarchies in dimensions have levels 
which can be used to view data at various levels of 
detail. A Time dimension might have levels for Year, 
Quarter, Month, and Day. A Product dimension 
might have levels for Product Family, Product Cat- 
egory, Product Sub-category, and Product Name. A 
Customer Geography dimension might have levels 
for Region, Country, District, State, City, and Neigh- 
borhood. 

Member: One of the data points for a level of a hi- 
erarchy of a dimension. Some of the members of 
the Month level of the Time dimension are January, 
February, March, and April. 

Measure: A numeric value stored in a fact table and 
in an OLAP cube. Sales Count, Sales Price, Cost, 
Discount, and Profit could all be measures in an 
OLAP cube. 

Multidimensional Analysis - also known as On-Line 
Analytical Processing (OLAP): A process of analy- 
sis that involves organizing and summarizing data 
in a multiple number of dimensions. People can 
comprehend a far greater amount of information if 
that information is organized into dimensions and 
into hierarchies. The wide use of spreadsheets and 
graphs illustrates the need for people to have their 
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information organized. A spreadsheet is a two-di- 
mensional analysis tool. If a person could compre- 
hend ten individual facts, they might possibly com- 
prehend 100 facts if they were arranged in a spread- 
sheet. Simplistically, if three or four or five dimen- 
sions were displayed, the amount of information 
that could be comprehended might increase expo- 
nentially - to 1 000 facts, 1 0,000 facts, and 1 00,000 
facts respectively. Multidimensional data is also or- 
ganized hierarchically, allowing users to "drill down" 
for more detailed information, "drill up" to see a 
broader, more summarized view, and "slice and 
dice" to dynamically change the combinations of di- 
mensions that are being viewed. 

Summary of the Invention 

[001 3] The present invention is designed to overcome 
at least some of the problems found in earlier systems, 
and also provide other advantages as will be clear from 
the following description. 

[0014] In the invention, a drill-through path is defined 
by a collection of parameter mappings that map context 
elements from the drill-through source (report) to the in- 
puts of the target. In addition to defining the target/ 
source mapping, these parameter mappings also define 
any translation, filtering, or formatting that may be re- 
quired. 

[0015] A parameter is a way of providing 'public' ac- 
cess to a column for external applications by giving it a 
name. More generally parameters define an input or out- 
put to a drill-through source or target. Additional param- 
eters may be used to select and define conversion func- 
tions for the parameter mappings in the drill-through 
process so that the invention also acts as a means for 
defining a data converter or filter. 
[0016] According to one aspect of the present inven- 
tion, there is provided a database interface for generat- 
ing drill-throughs of various data cubes, derived from dif- 
ferent report generating applications. The interface 
comprises: (a) means for accepting a request from a us- 
er for data; (b) means for translating the request into a 
drill-through selected from a plurality of possible drill- 
through paths between a source and a target; (c) means 
for applying one or more parameters to the selected drill- 
through path to produce a valid drill-through path and to 
transfer the requested data over the valid drill-through 
path to an application; and (d) display means for dis- 
playing the requested data to the user. According to an- 
ther aspect of the present invention, there is provided a 
computer-based method for obtaining data from one or 
more compatible data sources for use within applica- 
tions implementing a decision support system, the 
method comprising the steps of, in a business modeling 
tool before using a business intelligence application, (a) 
modeling a mapping of data between a source and a 
target to produce one or more possible drill-through 
paths between the source and the target, each drill- 



through path having one or more parameter mappings, 
in a business intelligence application, using a report au- 
thoring tool, (b) accepting a request from a user for data, 
(c) translating the request into a drill-through path se- 

5 lected from the possible drill-through paths between the 
source and the target, (d) applying one or more param- 
eters to the selected drill-through path to produce a valid 
parameter mapping and transferring the requested data 
over the valid parameter mapping to an application, and 

10 (e) displaying the requested data to a user. 

[0017] According to another aspect of the present in- 
vention, there is provided a computer-based system for 
obtaining data from one or more compatible data sourc- 
es for use within applications implementing a decision 

15 support system, the system comprising, in a business 
modeling tool, before using a business intelligence ap- 
plication, (a) means for modeling a mapping of data be- 
tween a source and a target to produce one or more 
possible drill-through paths between the source and the 

20 target, each drill-through path having one or more pa- 
rameter mappings, and in a business intelligence appli- 
cation, using a report authoring tool, (b) means for ac- 
cepting a request from a user for data, (c) means for 
translating the request into a drill-through path selected 

25 from the possible drill-through paths between the source 
and the target, (d) means for applying one or more pa- 
rameters to the selected drill-through path to produce a 
valid parameter mapping and to transfer the requested 
data over the valid parameter mapping to the applica- 

30 tion, and (e) display means for displaying the requested 
data to a user. 

[0018] According to another aspect of the present in- 
vention, there is provided an apparatus for obtaining da- 
ta from one or more compatible data sources for use 

35 within applications implementing a decision support 
system, the apparatus comprising, in a business mod- 
eling tool, (a) means for modeling a mapping of data be- 
tween a source and a target to produce one or more 
possible drill-through paths between the source and the 

40 target, each drill-through path having one or more pa- 
rameter mappings, and in a business intelligence appli- 
cation, using a report authoring tool, (b) means for ac- 
cepting a request from a user for data, (c) means for 
translating the request into a drill-through path selected 

45 from the one or more possible drill-through paths be- 
tween the source and the target, (d) means for applying 
one or more parameters to the selected drill-through 
path to produce a valid parameter mapping and to trans- 
fer the requested data over the valid parameter mapping 

50 to the application, and (e) display means for displaying 
the requested data to the user. 

[0019] A further understanding of other features, as- 
pects and advantages of the present invention will be 
realized by reference to the following description, ap- 
55 pended claims and accompanying drawings. 
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Brief Description of the Drawings 

[0020] A preferred embodiment(s) of the invention will 
now be described with reference to the following figures: 

Figure 1 shows the computer and related systems 
and connections within which the invention may be 
practiced; 

Figure 2 shows a simple situation in which a single 
parameter mapping defines a single item; 
Figure 3 shows a more complex example, in which 
there are several items, each defined by one or 
more parameter mappings; 

Figure 4 illustrates that there may be different func- 
tions related to each bi-directional parameter map- 
ping in a drill-through path; 

Figure 5 shows the necessary parameter mappings 
and drill-through paths for a situation where two 
business models must be integrated; 
Figure 6 is a more complex example, relating three 
business models; and 

Figure 7 is a further example, also showing the re- 
lationship with a Dimension Map. 

Detailed Description of the Preferred Embodiment 

(§) 

[0021] Typically, embodiments of the invention are 
practiced within a network of computers and related 
equipment as illustrated in Figure 1 . Data is stored in a 
data warehouse comprising files servers 100, 102, 104 
and storage devices 106, 108, with their related soft- 
ware applications (not shown), accessed from worksta- 
tions 1 1 0, 1 1 1 , 1 1 2 over a network 1 20, the workstations 
also including related software applications (not shown). 
[0022] Turning now to the Figure 2, a first preferred 
embodiment is shown in which an item 210, represent- 
ing a report column, or parameter, or some other ex- 
pression from a drill-through source or target, has a pa- 
rameter 200 exposed. The parameter mapping 240 from 
the item includes two optional mapping functions 220, 
230 which may translate the data from the outside world 
(using the parameter 200) to the item and vice-versa. 
[0023] Several optional functions made feasible by 
other preferred embodiments are describe below. One 
function already mentioned is the ability to translate or 
convert the data during the drill-through operation, and 
to select the actual conversion by means of a parameter. 
Earlier applications not incorporating embodiments of 
the present invention were only able to perform data 
conversion or manipulation of drill-through parameters 
within the report-producing application, and the required 
functions were stored with the report schema. This 
meant that the report was often used specifically for one 
drill-through since the report column used in the context 
filter would only make sense for that particular drill- 
through. By enhancing the drill-through service so the 
input and output conversion functions are part of the 



drill-through model it is possible to decouple them from 
the report itself (or its description and schema). In other 
words, any data conversions required for a drill-through 
path are encapsulated in the drill-through service, rather 

5 than in the report (and its schema). This is illustrated in 
the Figure 3, in which a drill-through source or target is 
generalized to a collection of parameters 300, 320, 340, 
360 as shown each related (or mapped) over a param- 
eter mapping including a function 305, 325, 345, 365 

10 respectively to one of the items 31 0, 330, 350. Note that 
more than one parameter can map to a single drill- 
though item as is shown in the figure 3, where parameter 
340 and parameter 360 both map to item 350 through 
their respective functions in parameter mappings 345, 

15 365. 

[0024] Another feature made possible by embodi- 
ments of the present invention is a drill-through path. A 
drill-through path is a collection of source and target pa- 
rameter mappingss. The drill-through path effectively 
20 couples the source and target objects together. A single 
drill-though target can have many drill-through sources 
and vise-versa. This aspect is illustrated in Figure 3, de- 
scribed earlier. 

[0025] Figure 4 shows an embodiment in which sev- 
25 eral bi-directional drill-through mappings are illustrated, 
400-402, 420-422, 430-432, 440-442, each having dif- 
ferent mapping functions for each direction, 404 and 
406, 424 and 426, 444 and 446, and 464 and 466. 
[0026] All of the various functions and mappings are 
30 captured and modeled using a single drill-through ad- 
ministration application. One preferred embodiment 
provides a single drill-through service that may be que- 
ried for drill-through information such as a list of targets 
from a given source or drill-through actions to be per- 
35 formed. 

[0027] The various concepts that are used in the new 
drill-through mechanism of the present invention will be 
described below. 

[0028] The invention solves several other problems 
40 found in earlier implementations. Since the drill-through 
source and targets are generalized as a collection of in- 
put and output parameters, it is no longer important to 
know in advance the actual drill-through target. This 
means, for example, that cubes built from data extracted 
45 from database "A" can still drill-through to a report 
whose data comes from database "B". It is the modeler's 
responsibility to ensure that the drill-through paths from 
the source and targets are properly matched up and the 
appropriate conversion functions are made available in 
50 the drill-through service. 

[0029] Provision of the new drill-through mechanism 
of the present invention allows the drill-through model 
to be used in defining an Internet Uniform Resource Lo- 
cator (URL) or a Hypertext Markup Language (HTML) 
55 FORM template, thereby providing for standard proce- 
dures in accessing data over the Internet. Therefore, in 
some preferred embodiments, a drill-through to any 
web-based target makes use of the generic ability to add 
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parameters to a URL or FORM template. For example, 
in a case where a template is a string containing one or 
more predefined drill -through parameter placeholders, 
defined as <P1>, <P2>... etc., a drill-through target is 
defined as a URL, using a well-known construction, for 
example: 

http://myserver/path/app.cgi?params=(<P1>, 
<P2>,<P3>) 

[0030] Consider the case of a report that contains 3 
columns named C1, C2, and C3. A drill-through path is 
defined that maps this source with the URL target. In 
this case the drill-through path is (C1->P1, C2->P2, 
C3->P3). Drilling from the source report at a specific row 
to the target means that the row values for C1 , C2 and 
C3 will be substituted into the URL at the P1, P2, and 
P3 placeholders, thereby producing a valid URL, for ex- 
ample: 

http://myserver/path/app.cgi?params=(C1 , C2, 

C3) 

[0031] A meta-data model is the model on which the 
reports are based. It is sometimes convenient to work 
with the underlying metadata, rather than the reports 
themselves. Therefore the concept of defining one or 
more drill-through paths between meta-data models will 
be described below. In the embodiments described 
above a drill-through model designer is able to define a 
drill-through path from one report to another. The de- 
signer (user) may optionally define any parameters to 
be used in the context filter when navigation from one 
report to another. In addition, drill-through services em- 
bodying the invention support the definition of one or 
more drill-through paths between the different meta-da- 
ta models. This has the advantage that reports based 
on the meta-data models can make implicit use of the 
already defined drill-through paths. The invention there- 
fore affords a generalized way of assigning drill-through 
paths between reports without having to explicitly define 
drill-through paths between all reports. This is done by 
providing a list of potential drill-through paths between 
the query items of a model. 

[0032] Various aspects of the use of the present in- 
vention are more fully explained by reference to the fol- 
lowing examples. 

[0033] Considering a situation where there are two 
different meta-data models. The first meta-data model 
is based on the "Sales" database and is used to allow 
the report writer to generate reports on all sales related 
information. The other meta-data model is based on the 
"Human Resources" database and allows report writers 
to generate reports of Personnel information. In some 
circumstances it is desirable to allow managers to drill- 
through from sales-based reports to personnel-based 
reports in order to answer questions such; "Is this indi- 
vidual's salary commensurate with his sales record?" 
[0034] We next describe in more detail how these 
kinds of queries are supported using embodiments of 
the present invention. In the Figure 5, the two database 
models, Sales 500 and Human Resources 520 are 



shown, together with relationships (or drill-through 
paths) 540 represented by lines drawn between the re- 
lated items representing their parameter mappings P1 
- P5. P1 - P5 are determined and suitably defined by a 

5 trained modeler experienced in the use of such systems. 
The Sales model includes two separate tables, namely 
SalesEmployee 502 and Sales Metrics 51 0, and the Hu- 
man Resources Model includes a Personallnfo table 
521 , and a Salarylnfo table 530. The relationships within 

10 540 represent the parameter mapping from one model 
to the other as previous described with reference to Fig- 
ures 3 and 4. In this case, the following parameter map- 
pings are defined: 

P1 between [SalesEmployee]. [EmployeeNum] 

15 503 and 

[Personallnfo]. [EmpNum] 522. 
P2 between [SalesEmployee]. [Manager] 505 and 
[Personallnfo]. [Name] 523. 

P3 between [SalesEmployee]. [EmployeeNum] 
20 503 and 

[Salarylnfo]. [EmpNum] 531. 
P4 between [SalesEmployee]. [Name] 504 and 
[Personallnfo]. [Name] 523. 

P5 between [SalesMetrics]. [EmployeeNum] 511 

25 and 

[Personallnfo]. [EmpNum] 522. 
[0035] Assume a source report is based on the Sales 
model (Sales) with the following columns; 

[SalesEmployee]. [Manager], [SalesEmployee]. 
30 [Name], 

total( [SalesMetrics]. [Revenue]) 
[0036] Further assume that the target report is to be 
based on the Human Resources model (HR info) with 
the following report columns; 
35 [Personallnfo]. [Name], [Personallnfo]. [Title], [Per- 

sonallnfo]. [Salary], 

[Personallnfo]. [LastRaiseDate] 
[0037] Note that it is not necessary to have parame- 
ters assigned to all of the query items. In this example 
40 [Personallnfo]. [Title] 524, and [Salarylnfo]. [LastRaise- 
Date] 532 are not assigned parameters. 
[0038] For the sake of simplicity no parameter map- 
ping functions are illustrated in this example. Their ad- 
dition and effect when required will be obvious to one 
45 skilled in the art. 

[0039] The report authoring tool first asks the drill- 
through service for a list of potential parameter map- 
pings in drill-through path that could be used to drill- 
through from the source report (Sales) 500 to the target 
50 report (HR Info) 520. The drill-through service employs 
the following algorithm to determine the mappings: 

1 . Create a list of parameters (query items) from the 
source report 500 and target report 520. 
55 2. For each source parameter determine a param- 
eter mapping that maps the parameter to the target. 
All defined parameter mappings are collected as a 
single drill-through path 
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3. If more than one parameter mapping points to the 
same target parameter then duplicate the parame- 
ter mapping one for each duplicate target mapping. 
For example, in Figure 5 there are potentially two 
parameter mappings pointing to the same target 
[Personallnfo].[Name] 523. As a result, two sepa- 
rate parameter mappings are created from the 
sources [SalesEmployee].[Name] 504 and 
[SalesEmployee]. [Manager] 505. These parameter 
mappings are P2 and P4 within the drill-thorough 
path 540. This duplication prevents any conflicts 
when the filter is formed. 

4. Continue duplicating until all the parameter map- 
pings for the drill-through path point to unique target 
parameters. 

[0040] In this example, after completion of the above 
algorithm, the following parameter mappings from 
among those possible 540 will be returned from the drill- 
through service: 

Parameter mapping #1 (P4) and 
Parameter mapping #2 (P2). 

[0041 ] Using these parameter mappings it is possible 
to drill-through from the sales report to the HR report 
and filter on either the salesperson's name or on the 
manager's name. The parameterised drill-through serv- 
ice of the present invention therefore allows the user to 
obtain the answer to either or both of the two questions: 

1. "How much am I paying a sales person relative 
to their generated revenue?" and 

2. "How much am I paying a manager relative to the 
total revenue of the sales people being managed?" 

[0042] Only a single parameter mapping for each drill- 
through path is used here since only one parameter is 
matched from source to target. Generally, a drill-through 
path may contain any number of applicable parameter 
mappings. 

[0043] Since it cannot be known in advance what 
parts of the report a model may use, a drill-through path 
is fully defined during the modeling phase. Therefore a 
collection of parameter mappings (P1 -P5) 540 is provid- 
ed from which the actual drill-through path can be built 
dynamically depending on what columns (parameters) 
are available in the source and target reports. 
[0044] It is possible to have more than one parameter 
mapping generated, as shown here, so that a drill- 
through path selection must be made by the user. 
[0045] Expanding on this general model of drill- 
through usage, it is also possible to define general drill- 
through paths from a meta-data model to specific re- 
ports. Figure 6 shows a Sales model 600 having two 
drill-though paths 630, 635 defined to two separate re- 
ports: an Order Detail Report 620 and an Employee Ex- 
penses Report 625. 



[0046] One of the parameter mappings of the "Order- 
Detail" drill-through path 630 maps [SalesMetrics].[Or- 
derNum] 605 to report column "Order Number" 621 . The 
"Expenses" drill-through path 635 contains a single pa- 

5 rameter mapping on [SalesEmployee]. [EmployeeNum] 
602 to report column "Employee Number" 626. In some 
cases other parameters are available to be used in other 
instances of using the drill-through service. In some cas- 
es it is up to the drill-through target report to dispense 

10 with unnecessary filtering as part of any optimisation. 
[0047] Once these drill-through services indicated by 
the paths 630, 635 have been defined, then any report 
that included either or both of the Sales Model 600 items 
[SalesModel]. [SalesEmployee]. [Name] 603 and 

15 [SalesModel]. [SalesMetrics].[OrderNumber] 605 can 
drill-through to the OrderDetail report 620. Similarly any 
report that includes a report column based on 
[SalesEmployee]. [EmployeeNum] 602 can drill-through 
to the Employee Expenses report 625. 

20 [0048] This next example describes the drill-through 
parameter mapping to and from OLAP sources to mod- 
els for relational reporting tools. 

[0049] Referring to the Figure 7, a cube 710 (repre- 
sented in this diagram as being derived from a dimen- 
25 sion map 700 by a suitable transformation tool 705) has 
a set of parameters which are the dimension levels. 
Each level is represented by (or exposed as) a param- 
eter. 

[0050] In one case a drill-through path 790 is defined 
30 from the cube 71 0 to the report OrderDetail Report 760, 
the path having two parameters mappings (OrderNum) 
761, (Outlet) 762. 

[0051] In another case the cube parameters 710 are 
mapped to a model. This is a generalized case which is 

35 similar to the model to model case previously described. 
Drill through paths 795 and their related parameter map- 
pings 781 are defined between the cube 710 and the 
Model 780. As a consequence, any reports that are 
based on the model can drill through into the cube as- 

40 suming that the required parameters (columns) are in- 
cluded in the report. 

[0052] It has been found that significant savings are 
realised in terms of the number and the updating of drill- 
through paths, when compared to the situation before 

45 the availability of parameterised drill-through paths and 
their associated parameter mappings. 
[0053] While various embodiments of the present in- 
vention have been described above, it should be under- 
stood that they have been presented by way of example 

50 only, and not limitation. It will be understood by those 
skilled in the art that various changes in form and details 
may be made therein without departing from the spirit 
and scope of the invention as defined in the appended 
claims. Thus, the breadth and scope of the present in- 

55 vention should not be limited by any of the above-de- 
scribed exemplary embodiments, but should be defined 
only in accordance with the attached or associated 
claims and their equivalents. 
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[0054] The invention can be implemented in digital 
electronic circuitry or in computer hardware, firmware, 
and software or in combinations thereof. Apparatus of 
the present invention can be implemented in acomputer 
program product tangibly embodied in a machine-read- 
able storage device for execution by a programmable 
processor. The method of the present invention can be 
performed by a programmable processor executing a 
program of instructions to perform the functions of the 
invention by operating on input data and generating out- 
put. 



Claims 

1. In a decision support system, an interface for gen- 
erating drill-through paths comprising: 

(a) means for accepting a request from a user 
for data; 

(b) means for translating the request into a drill- 
through path selected from a plurality of possi- 
ble drill-through paths between a source and a 
target; 

(c) optional means for applying one or more pa- 
rameters to the selected drill-through path to 
produce a valid drill-through path and to trans- 
fer the requested data over the valid drill- 
through path to an application; and 

(d) display means for displaying the requested 
data to the user. 

2. A computer-based method for obtaining data from 
one or more compatible data sources for use within 
applications implementing a decision support sys- 
tem, the method comprising the steps of: 

in a business modeling tool before using a busi- 
ness intelligence application, 

(a) modeling a mapping of data between a 
source and a target to produce one or more 
possible drill-through paths between the 
source and the target, each drill-through 
path having one or more parameter map- 
pings; 

in a business intelligence application, using a 
report authoring tool, 

(b) accepting a request from a user for da- 
ta; 

(c) translating the request into a drill- 
through path selected from the possible 
drill-through paths between the source and 
the target; 

(d) applying one or more parameters to the 
selected drill-through path to produce a 



valid parameter mapping and transferring 
the requested data over the valid parame- 
ter mapping to an application; and 
(e) displaying the requested data to a user. 

5 

3. A computer-based method for obtaining data from 
one or more compatible data sources for use within 
applications implementing a decision support sys- 
tem wherein there is an a business intelligence ap- 

10 plication, using a report authoring tool, which ac- 
cepts a request from a user for data, translates the 
request into a drill-through path selected from the 
possible drill-through paths between the source and 
the target, applies one or more parameters to the 

15 selected drill-through path to produce a valid pa- 
rameter mapping and transfers the requested data 
over the valid parameter mapping to an application, 
and displays the requested data to a user, the meth- 
od comprising: 

20 

(a) modeling a mapping of data between a 
source and a target to produce one or more 
possible drill-through paths between the source 
and the target, each drill-through path having 
25 one or more parameter mappings. 

4. A computer-based method for obtaining data from 
one or more compatible data sources for use within 
applications implementing a decision support sys- 

30 tern wherein there is a tool to model the mapping of 
data between a source and a target to produce one 
or more possible drill-through paths between the 
source and the target, each drill-through path hav- 
ing one or more parameter mappings, the method 

35 comprising the steps of: 

(a) accepting a request from a user for data; 

(b) translating the request into a drill-through 
path selected from the possible drill-through 

40 paths between the source and the target; 

(c) applying one or more parameters to the se- 
lected drill-through path to produce a valid pa- 
rameter mapping and transferring the request- 
ed data over the valid parameter mapping to an 

45 application; and 

(d) displaying the requested data to a user. 

5. The method of claim 2 wherein the translating step 
includes the steps of: 

50 

(a) creating a list of parameters (query items) 
from source and target reports; 

(b) for each source parameter, determining a 
parameter mapping that maps the parameter to 

55 the target and collecting them as a single drill- 

through path; 

(c) if more than one parameter mapping points 
to the same target parameter then duplicating 
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the parameter mapping one for each duplicate 
target path, thereby avoiding conflicts in form- 
ing the filter path; and 

(d) continuing to duplicate the parameter map- 
pings until all the parameter mappings for each 5 
drill-through path point to unique target param- 
eters. 

6. The method of claim 5 wherein the source and the 
target are each of types which are selected from a 10 
group consisting of report and model. 



pings one for each duplicate target path to 
avoid conflicts in forming the filter path. 

12. The system of claim 1 0 wherein the source and the 
target are each of types which are selected from a 
group consisting of report and model. 

13. The system of claim 10 wherein the source is of a 
type selected from a group consisting of report and 
model and the target is a cube derived from a di- 
mension map using a transformation tool. 



7. The method of claim 5 wherein the source is of a 
type selected from a group consisting of report and 
model and the target is a cube derived from a di- 15 
mension map using a transformation tool. 

8. The method of claim 5 wherein the drill-through path 
is defined by Uniform Resource Locator (URL). 

20 

9. The method of claim 5 wherein the drill-through path 
is defined by an HTML FORM. 

10. A computer-based system for obtaining data from 
one or more compatible data sources for use within 25 
applications implementing a decision support sys- 
tem, the system comprising: 

(a) means for modeling a mapping of data be- 
tween a source and a target to produce one or 30 
more possible drill-through paths between the 
source and the target, each drill-through path 
having one or more parameter mappings; 

(b) means for accepting a request from a user 

for data; 35 

(c) means for translating the request into a drill- 
through path selected from the possible drill- 
through paths between the source and the tar- 
get; 

(d) means for applying one or more parameters 40 
to the selected drill-through path to produce a 
valid parameter mapping and to transfer the re- 
quested data over the valid parameter mapping 

to the application; and 

(e) display means for displaying the requested 45 
data to a user. 

11. The system of claim 10 wherein the means for 
translating further comprises: 

50 



14. The system of claim 10 wherein the drill-through 
path is defined by a Uniform Resource Locator 
(URL). 

15. The system of claim 10 wherein the drill-through 
path is defined by an HTML FORM template. 

16. An apparatus for obtaining data from one or more 
compatible data sources for use within applications 
implementing a decision support system, the appa- 
ratus comprising: 

(a) means for modeling a mapping of data be- 
tween a source and a target to produce one or 
more possible drill-through paths between the 
source and the target, each drill-through path 
having one or more parameter mappings; 

(b) means for accepting a request from a user 
for data; 

(c) means for translating the request into a drill- 
through path selected from the one or more 
possible drill-through paths between the source 
and the target; 

(d) means for applying one or more parameters 
to the selected drill-through path to produce a 
valid parameter mapping and to transfer the re- 
quested data over the valid parameter mapping 
to the application; and 

(e) display means for displaying the requested 
data to the user. 

17. Computer executable software code stored on a 
computer readable medium, the code for obtaining 
data from one or more compatible data sources for 
use within applications implementing a decision 
support system, the code comprising, 

(a) code for modeling a mapping of data be- 
tween a source and a target to produce one or 
more possible drill-through paths between the 
source and the target, each drill-through path 
having one or more parameters; 

(b) code for accepting a request from a user for 
data; 

(c) code for translating the request into a drill- 
through selected from the one or more possible 



(a) means for creating a list of parameters (que- 
ry items) from source and target reports; 

(b) means for determining, for each source pa- 
rameter, a parameter mapping that maps the 
parameter to the target; 55 

(c) means for collecting the parameter map- 
pings as a single drill-through path; and 

(c) means for duplicating the parameter map- 
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drill-through paths between the source and the 
target; 

(d) code for applying one or more parameters 
to the selected drill-through path to produce a 
valid parameter mapping and to transfer the re- 5 
quested data over the valid parameter mapping 

to the application; and 

(e) code for displaying the requested data to the 
user. 

10 
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